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ABSTRACT 


Aircraft flight characteristics at high angles of attack can be improved by controlling vortices 
shed from the nose. These characteristics have been investigated with the integration of the actu- 
ated nose strakes for enhanced rolling (ANSER) control system into the NASA F-18 High Alpha 
Research Vehicle. Several hardware and software systems were developed to enable performance 
of the research goals. A strake interface box was developed to perform actuator control and failure 
detection outside the flight control computer. A three-mode ANSER control law was developed 
and installed in the Research Flight Control System. The thrust-vectoring mode does not command 
the strakes. The strakes and thrust-vectoring mode uses a combination of thrust vectoring and 
strakes for lateral-directional control, and strake mode uses strakes only for lateral-directional 
control. The system was integrated and tested in the Dryden Flight Research Center (DFRC) sim- 
ulation for testing before installation in the aircraft. Performance of the ANSER system was mon- 
itored in real time during the 89-flight ANSER flight test program in the DFRC Mission Control 
Center. One discrepancy resulted in a set of research data not being obtained. The experiment was 
otherwise considered a success with the majority of the research objectives being met. 
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INTRODUCTION 


The F-18 High Alpha Research Vehicle (HARV) flown at Dryden Flight Research Center 
(DFRC), Edwards, California, is a flight test platform for the High-Angle-of-Attack Technology 
Program (HATP). One HATP objective involves improving aircraft controllability and agility at 
high angles of attack (ref. 1 ). The first phase of the program investigated high-angle-of- attack aero- 
dynamics in a baseline F-18 configuration. During the second phase, the aircraft was modified by 
integrating a research flight control system (RFCS) with the basic F-18 control system. The RFCS 
allows various flight control laws to be flown. The standard F-18 system provides input, output, 
redundancy management, and safe backup for the RFCS. A thrust-vectoring (TV) system was also 
added to the HARV. This modification includes the addition of TV vanes to deflect engine exhaust 
for high-angle-of-attack maneuvering. 

The third and final phase investigated an alternate control methodology for high-angle-of- 
attack maneuvering. Langley Research Center (LaRC), Hampton, Virginia, developed a system to 
apply forcing moments to the nose of the aircraft by controlling the vortices shed from the nose at 
high angles of attack (ref. 2). The actuated nose strake for enhanced rolling (ANSER) system con- 
sists of two actuated control surfaces installed in a specially constructed radome (fig. 1). 
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Figure 1 . The F- 1 8 HARV. 


The DFRC integrated the ANSER system with the RFCS and aircraft systems and conducted 
the flight research to accomplish these tasks. Several hardware and software systems were 
designed and developed. This paper describes the systems developed to integrate the ANSER into 
the aircraft and integration testing. Some of the technologies developed to enable accomplishment 
of the research objectives are discussed. Use of trade names or names of manufacturers in this 
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document does not constitute an official endorsement of such products or manufacturers, either 
expressed or implied, by the National Aeronautics and Space Administration. 


SYSTEM OVERVIEW 


The ANSER installation was designed to use full actuator authority to provide 90° of strake 
deflection (fig. 1). These strakes are commanded independently by control laws residing in the 
RFCS computers with two independent channels controlling each strake. The RFCS computers are 
F-18 flight control computers modified by the addition of a second processor running parallel and 
sharing data with the main processor. Figure 2 shows a top-level diagram of the control system. 
The RFCS software is written in Ada and cross-compiled on a UNIX®-based workstation. The 
compiled software is then downloaded to the RFCS. 



Figure 2. The F-18 HARV ANSER control system. 


The RFCS control laws can be engaged with weight on the wheels or when the aircraft is in a 
predefined Mach number, M, and altitude, h, flight envelope (15,000 ft < h < 45,000 ft, M < 0.7) 
by first arming the system with a cockpit-mounted toggle switch, then engaging with a push button 
on the control stick. Research objectives required operation of the strakes both in conjunction with 
and independent of the TV system, resulting in a multimode control law implementation. Upon 
engagement, the RFCS defaults to TV mode in which the strakes are commanded closed at all 
times. Strakes and thrust-vectoring (STV) and strake (S) modes are selectable via a push button on 
the digital display indicator (DDI). 


®UNIX is a registered trademark of UNIX System Laboratories, Inc. 
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Unlike the other control surfaces, which are only commanded by the RFCS control laws while 
RFCS is engaged (ref. 3), the strakes are commanded by the RFCS control laws at all times through 
previously unused analog outputs. Similarly, actuator control for the conventional surfaces and TV 
vanes are performed by the flight control computer (FCC); meanwhile, the strakes are controlled 
by an external interface box. 


HARDWARE DESIGN AND IMPLEMENTATION 


Control of the strakes is performed by two electrically controlled, hydraulically powered 
servoactuators. These actuators are F- 18 aileron actuator servovalves mounted to a longer, narrow- 
er main piston and cylinder. The strake actuator piston length is 5.68 in. ±0.05 in. in place of the 
4.38 in. ±0.05 in. as installed on the standard actuator. The actuators are dual redundant. Either 
channel can drive the surface. Hydraulic supply is single string to both actuators. The hydraulics 
are plumbed to the gun hydraulic quick disconnect located in the nose barrel section of the aircraft. 

Integration of the strake actuators with the FCS required the addition of actuator control loop 
closure and failure detection for the strake actuators. These functions are normally performed in 
the FCC software. However, insufficient FCC input-output (I/O) availability required implemen- 
tation of these functions external to the FCC in a strake interface box (SIB). The RFCS strake com- 
mands are passed through a previously unused digital-to-analog converter (DAC) to the servoloop 
located in the SIB. The servoloop performs loop closure and sends a rate command to the actuator. 
Several control loop signals are monitored by the failure-detection circuitry, which sends a go/no 
go signal back to the RFCS via a previously unused analog-to-digital converter (ADC). If a no go 
signal is received, the RFCS automatically reverts to TV mode and commands the strake to close. 
The SIB contains two independent channels of actuator control and failure detection. Each SIB 
channel controls one channel of each actuator (fig. 2). 

Because the actuators used to drive the strakes are modified F-18 actuators, spare servoloop 
circuit cards were modified for use in the SEB to reduce manufacturing costs for a newly designed 
card. These cards were originally designed for use in the thrust-vectoring vane (TVV) system. The 
servoloop cards contain three identical servoloops of which two were used for the strake system. 
Figure 3 shows a block diagram of the servoloop board. Servoloop integrity is monitored by com- 
paring the command output to that of a servoloop model which runs in parallel with the actual 
servoloop. A miscompare results in generation of a failure signal which is passed to the failure- 
detection circuitry for system monitoring. In addition to the servoloop function, this card performs 
all signal conditioning necessary for signal usage by the failure -detection logic. The card also re- 
ceives discrete information back from the failure-detection logic for use in the servovalve and shut- 
off valve driver circuitry. This card was originally intended to be addressed by the FCC, so minor 
modifications were made to permanently enable discrete I/O of the board. A 1.8432-MHz clock 
was also added to these boards to trigger a programmable array logic (PAL) integrated circuit. 

The software failure detection routines implemented in the FCC for the TVV actuators were 
also implemented in the SIB for the strake system. These routines include a comparison of servo- 
valve command current to servovalve position (fig. 4), a main ram linear variable displacement 
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Figure 3. Servoloop card. 



Figure 4. Spool position versus servocurrent test. 


transformer (LVDT) monitor (fig. 5), and a hydraulic pressure sensor monitor (fig. 6). Each of 
these tests generates a discrete signal which is passed back to the servoloop board for actuator shut- 
off valve and servovalve relay control. Figure 7 shows the relay control logic. As shown in figure 7, 
the failures would self-reset upon clearing with no manual reset capability. A built-in test (BIT) 
circuit was integrated into the design which sequentially interrupts various actuator control signals 
to verify the integrity of the failure-detection circuitry (fig. 8). Because a processor was not 
designed into the system, monitoring of the BIT was performed manually in the Mission Control 
Center (MCC) before each flight. Although not as efficient as an automatic system, this approach 
proved adequate for this system. 
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Figure 5. Ram LVDT monitor. 
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Figure 6. Hydraulic pressure monitor. 
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Spool position 
versus current 



Figure 7. Failure logic. 
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Figure 8. The ANSER built-in test. 
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The SIB is powered by two independent power supply modules which regulate aircraft 28 Vdc 
and convert it to ±15 Vdc, 5 Vdc, and 8 Vrms LVDT excitation. The LVDT excitation frequencies 
are programmable by selecting one of various jumper configurations at the power supply. To elim- 
inate beat frequency development between channels, the two strake channels were given different 
LVDT excitation frequencies. As with the servoloop boards, existing FCC power supplies were 
used to eliminate development costs. The power supply modules, servoloop boards, and failure- 
detection boards were housed in a locally manufactured enclosure (fig. 9). The box was mounted 
in the radome aft of and between the strake actuators. 
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Figure 9. Power supply modules, servoloop boards, and failure-detection boards. 

The design goal for the strake control system was fail-operate/fail-safe. The fail-safe mode 
placed the affected actuator into trail-damped mode, in which the actuator shutoff valves are 
opened, causing hydraulic fluid to bypass the main ram. The surface then floats freely, thus not 
generating a forcing moment on the aircraft. However, testing showed that the airflow over the 
strake did not generate enough force to overcome the breakout force and friction of the strake 
actuator and linkage while in trail-damped mode. Thus, the strake was essentially stuck in its last 
position. Evaluations of a stuck strake conducted in the DFRC F-18 simulation showed that an un- 
recoverable departure could occur at angles of attack of 50° or higher with a strake fully deployed. 
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This discovery led to implementation of a pilot-initiated system to bypass the control system and 
force the strakes to the fully retracted position in the event of a stuck strake. A switch added to the 
cockpit provided power to four independent relays which overrode the shutoff valves and com- 
manded the actuators to fully retract independent of the control system commands. Figure 10 
shows this logic. 


SIB 


Strake override switch 



Figure 10. Strake retract system. 


Cockpit modifications to accommodate the strake system were minimal. In addition to the 
strake retract switch, two toggle switches were added to initiate the BIT logic. Two override 
switches were also added to manually interrupt the shutoff valve driver signal and place the 
actuators in the trail-damped mode. The override switches were only used in ground operations 
although no measures were taken to prohibit their functionality in flight. A failure indication was 
added to the warning light panel to indicate any failures in the system. Display modifications that 
required updates to the mission computer (MC) software included the addition of a mode transition 
button and a gain select button to the FCS display on the DDI and a mode and gain set display on 
the head-up display (HUD). Figures 1 1 and 12 show the DDI and HUD symbologies. The onboard 
augmented vehicle (OAV) engagement button and maneuver selections button for the onboard 
excitation system (OBES) were already present from phase 2 of flight test. The FCS DDI page was 
used to select ANSER modes, dial-a-gain settings, OAV maneuvers, and OBES engagement. The 
HUD was used to display RFCS engagement, OBES engagement, ANSER modes, and dial-a-gain 
settings. No indication of strake position was presented in the cockpit. 
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GAIN select button 



Figure 1 1 . Flight control system display. 
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Figure 12. The HARV head-up display. 


SOFTWARE DESIGN AND IMPLEMENTATION 


The ANSER software was developed using two methods: hand coding from a specification and 
automatic code generation. The software for the ANSER can be divided into nine elements. These 
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elements consist of the existing shell, lateral-directional control laws, longitudinal control laws, 
pseudocontrols, TV mixer (ref. 4), mode logic, G-disengage, dial-a-gain, and OBES. This section 
discusses these software elements and design methodologies in more detail with the exception of 
the TV mixer. 

The RFCS executes at 160 Hz in 16 minor frames; the longitudinal control laws execute at 
80 Hz in the even minor frames; and the lateral-directional control laws, pseudocontrols, and 
TV mixer execute at 80 Hz in the odd minor frames. Each minor frame is 6.25 msec long with 
the requirement that the RFCS commands to the processor be computed by the 2.2-msec mark. 
These 2.2 msec were the critical throughput requirement. Read-only memory (ROM) was also a 
concern. The RFCS had only 32 kilobytes of electrically erasable programmable read-only 
memory (EEPROM). 


Hand-Coded Software 


The ANSER control law software was designed and developed from the HARV ANSER con- 
trol law specification written by the Vehicle Dynamics and the Dynamics and Controls Branches 
of LaRC. Existing RFCS software was used as a baseline for the ANSER control laws (ref. 5). The 
control law software was removed, and the existing shell containing the multirate structure, 
disarm-disengagement logic, gross thrust estimator, and RFCS I/O software was retained (fig. 13). 
The TV portion of the ANSER control laws was implemented and flown first independently from 
the strake interfaces, followed by the complete ANSER control laws. 


Control 
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RFCS no go 
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Control 

commands, Control Control 
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computed computed 
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Figure 13. The RFCS shell. 


Because of limited memory and throughput of the RFCS, the code was periodically reworked 
to reduce the amount of memory it used. To reduce the risk of throughput problems, the software 
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was written as efficiently as possible. The multirate structure only processed inputs at the rate and 
frame at which they were updated. Airdata and inertial navigation system (INS) angles were input 
at 20 Hz. Angle of attack (AO A) and angle of sideslip rate (0) inertial were input at 40 Hz. 
Although pilot commands and rate and acceleration feedbacks were input at 40 and 80 Hz, the 
40 Hz signals were processed at 80 Hz and averaged to provide continuous data to the control laws. 
Only processing required to compute command outputs was completed in the critical first 
2.2 msec. All other computations were processed after completion of the command output compu- 
tation but before the 6.25 msec end of frame. 

Using the horizontal block diagrams provided in the control law specification, a control law 
input listing was generated to verify that the required inputs were available to the control laws. 
Next, each axis was modularized, and data flow paths were determined. Figure 14 shows an exam- 
ple of a data flow path diagram. Once the data flow was determined, the execution order of the 
modules was easily determined based on the data flow. The execution order ensured that outputs 
were computed before being used as inputs to other portions of the system. Once the data flow, 
execution order, computation rates, input availability, and software modularity were determined, 
the software was coded. The review process at the code level consisted of informal code reviews 
and limited module level and end-to-end testing. The module level and end-to-end testing were 
performed using the RFCS source code on a workstation. 



Figure 14. Lateral-directional control law data flow. 


Automatic Code Generation 


In developing the ANSER control laws specification, LaRC extensively used computer 
generated software code in both FORTRAN and Ada using MATRIX x .® Using automatic code 


®MATRIX X is a registered trademark of Integrated Systems, Inc., Palo Alto, California. 
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generation reduced the time required to make changes to the control law and to evaluate the 
changes in simulation, thus shortening the time required between control law modification and 
flight test. 

The FORTRAN from the automatic code generation was used in the LaRC simulations and in 
the DFRC batch simulation. When changes were made to the control laws, software was regener- 
ated using the automatic code generator and interfaced to the simulations. Check-case scripts and 
time histories were also provided for use in verifying the implementation. This procedure offered 
considerable savings in time over the traditional process of hand-coding the changes, evaluating 
them, and then providing the changes to programmers in the form of block diagrams to be hand- 
coded in that simulation. Of course, small changes, such as changing the values of a few vari- 
ables, were still completed by hand directly in the code. 

To complete this process of automation, carrying the automatic code generation all the way to 
flight was desired. Some obstacles were in this path, however. The automatically generated code 
was not as efficient as hand-coded software in terms of execution speed and memory. This obsta- 
cle was serious because the RFCS was operating near capacity in memory and execution time. 
Second, the software generation tool did not include a multirate capability. In spite of these 
obstacles, it was decided to use the automatically generated code for the pseudocontrols portion 
of the lateral-directional control law to run in the RFCS. The automatically generated code for 
the pseudocontrols was modified to accommodate the differences between the simulations and 
the RFCS. 


Mode Logic 


Because the ANSER control laws had three separate control law modes (TV, STV, and S), 
allowing in-flight selections of these modes was required. A mode selection system was, therefore, 
incorporated into the RFCS. Thrust vectoring was selected as the default mode; therefore, when- 
ever RFCS was not engaged, the controls laws were in the TV mode. In addition, upon RFCS 
engagement, the TV mode was selected. Transitions to the STV and S modes were performed 
through a single mode select button on the FCS page on the DDI. A single button was used because 
of memory constraints in the MC. The pilot uses this mode select button to toggle through the 
modes, TV STV -» S -» TV (fig. 15). These modes were then displayed on the HUD and down- 
linked to the control room. 

Because a 1- to 2-sec fade existed between the modes, the HUD mode indication would be “X” 
so that the pilot was aware that a mode transition was in progress. The RFCS disengages requests 
through the paddle switch functioned from any mode. A strake failure indication from the SIB 
would force a mode transition back to the TV mode. Early in the design the decision to allow the 
pilot to remain in TV following a strake failure was made. The TV can provide greater control pow- 
er to recover from abnormal conditions that might occur when recovering from a strake failure. 
This failure indication was latched in the RFCS software so that the failure reason could be deter- 
mined in the control room before the pilot was allowed to reselect a strake mode. To limit the 
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aircraft to benign flight conditions during mode selections, the listed mode transition limits for 
TV — > STY and STY — > S were defined in the software as done for RFCS arming. 



Pilot selected mode transition. 

(RFCS disengage to production FCS was available from all modes.) 


► Automatic down mode to TV mode due to strake failure 

(strake go = false). (Automatic downmode to TV gives pilot 
option to recover from strake failure with TV enabled.) 9604u 

Figure 15. The ANSER mode transitions. 

Table 1 lists the mode transition limits. The limit on AOA was a place holder in the software 
in case a smaller limit was desired. For S -» TV transitions, these limits were set at or near maxi- 
mum sensor values to allow the pilot to select the TV mode throughout the RFCS envelope. 


Table 1 . Mode transition limits. 


Signal 

Limit 

Roll rate 

< ±30°/sec 

Pitch rate 

< ±15°/sec 

Yaw rate 

< ±15°/sec 

Lateral acceleration 

< ±0.5 g 

Normal acceleration 

> -1 g or < 2 g 

Angle of attack 

< ±360° 

Sideslip rate inertial 

< ±5°/sec 


OBES and Dial-A-Gain. 


Although not new for ANSER, the OBES was used extensively during ANSER research 
flights. The OBES portion of the RFCS software was originally designed as a structural 
mode excitation system, but it has evolved into a multidisciplinary, on-aircraft test facility. The 
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growing number of useful applications includes aerodynamic measurements and flow visualiza- 
tion, parameter identification, control law evaluation, in-flight control law variability, handling 
qualities and inner loop stability analysis, simulation model verification, and ground test of new 
aircraft systems. 

The initial set of research TV control laws required active in-flight structural mode excitation. 
This requirement resulted from marginal aeroservoelastic stability analysis predictions. Different 
excitation concepts were considered. An external mechanical excitation system was not selected 
because of its intrusive nature and integration difficulties. Another concept considered was to use 
the remotely augmented vehicle (RAV) facility. The RAV facility has been a critical test facility 
at DFRC for remote maneuver guidance, control augmentation, and remote piloting. This facility 
could be used to up-link an excitation signal to the aircraft which would then need to be received, 
processed and passed to the RFCS. The signal would then be summed to the desired control surface 
command. By driving the selected control surfaces at varying frequencies, the structural modes of 
the aircraft could be excited. The frequencies of the structural modes of interest were well within 
the bandwidth of the F- 1 8 actuators. 

The OBES was created by adapting this latter concept. Taking advantage of the imbedded and 
programmable RFCS, the functions of the RAV facility were effectively brought onboard the air- 
craft. With this OBES configuration, the RAV functions were performed internal to the aircraft, 
thus eliminating the problems associated with the remote facility. Some of the problems addressed 
include the up-link and down-link range and dropout problems, on-aircraft receiver requirements, 
signal processing, redundancy management, and time delay. Other RAV drawbacks eliminated by 
the OBES include the need for manpower support during the flights as well as dependence on a 
complex system of hardware and software. 

The OBES generates the desired function and sums the signal to the desired RFCS control law 
path (fig. 16). The function generation logic and signal superposition are performed within the 
RFCS Ada software, and the selected OBES function identifier is down-linked to the control room 
for test point verification. For these flight test points, the test pilot would simply initiate the appro- 
priate OBES maneuver and maintain flight conditions. The OBES performs the selected maneuver. 
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command 
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command 
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Figure 16. The OBES command summation examples. 
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For ANSER flight testing, the OBES was used for nose strake aerodynamic measurements and 
flow visualization, nose strake loads flight clearance, closed- and open-loop parameter identifica- 
tion and nose strake preflight built-in test excitation. 

A dial-a-gain capability was added to the RFCS to add flexibility to the flight test of the 
ANSER control laws. The option of eight separate gain set selections was made available. For 
ANSER, three gain sets were defined for the longitudinal axis with one gain set defined as a 
default, baseline set. These gain sets were selected through the cockpit DDI, and the current gain 
set was displayed on the HUD and down-linked for control room monitoring. Gain selection was 
allowed throughout the flight envelope before or after RFCS engagement; however, with any 
RFCS disengagement, the selected gain set defaulted back to the baseline gain set. 


g-Disengage 


The RFCS and Ada software were originally intended to be a class B system to reduce the 
software testing and verification requirements (ref. 3). Although many definitions of class B exist, 
in general this designation meant that an error in the RFCS or software could not result in loss 
of aircraft. 

Vehicle modifications required by the installation the TVCS and ANSER systems added a 
significant amount of weight at the extreme fore and aft ends of the aircraft. Because of this “flying 
dumbbell” configuration, expected load levels in the forward fuselage area during maneuvering 
flight were significantly increased. Structural analysis indicated that a reduction in symmetric and 
asymmetric maneuvering load limits was required (table 2). Software modifications to enforce 
the new limits could not be made to the basic flight control system, so a flight operations limit 
was imposed. 


Table 2. Production F/A-18 and HARV load limits. 


Load limit 

Production F/A-18 

HARV 

Symmetric 

-3.0 g to 7.6 g 

-2.0 g to 5.4 g 

Asymmetric 

0 g to 6.0 g 

0 g to 4.2 g 


Although the flight operations limit specifically restricts the pilot from maneuvering above the 
symmetric and asymmetric load limits, the aircraft still has the command authority and control 
power available to significantly exceed the aircraft structural limits in the lower right-hand corner 
of the RFCS envelope ( h = 1 5,000 ft, M = 0.7). During software testing, it was found that hard-over 
stabilator commands from the RFCS could not be countered by the pilot in enough time to prevent 
an over-g. As a result to balance the risk of an undetected RFCS software fault with the general 
desire to design and test in a class B environment, a function to predict and reduce the possibility 
of an over-g was implemented in the RFCS. 
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This function, called the g-disengage, was only active at high dynamic pressures where an 
over-g was possible. Structural loads in the critical forward fuselage area were estimated from 
flight control accelerations and rates and projected ahead in time with a lead filter. When the pro- 
jected load exceeded the computed load limits, the RFCS stayed engaged. However, the RFCS sta- 
bilator command was ignored, and the stabilator was driven to the basic F/A-18 stabilator 
command. Once the stabilator got within 5° of the basic system stabilator command, the RFCS was 
disengaged. In this way, the g-disengage reduced the potential of an over-g caused by a failure in 
the RFCS. It dynamically limited the stabilator commands. 

Once the g-disengage software was implemented, it was complied and stored in a designated 
portion of the EEPROM. This designation was done so that when software updates were made, 
a bit-for-bit comparison could be completed using the previous version of g-disengage. This 
comparison ensured that any software updates to the RFCS did not affect the g-disengage portion 
of the software. 


SYSTEM INTEGRATION AND TESTING 


The ANSER system was extensively tested before it was integrated into the aircraft. Testing 
was broken into four levels: card level testing, box level, integrated system, and system validation. 
The designer performed card level testing to check the design and build of the card. Each card was 
tested against the design as much as possible. The chassis wiring was also tested at this level. 
Box level testing was a more intensive test and was integrated with an actuator and an actuator 
model. Integrated system testing included the FCS and the actuators or actuator models. System 
validation testing included the actuators or actuator models, FCC, and closed-loop simulation of 
the vehicle dynamics. 

An actuator model was developed for the integration and testing of the strake system. The 
strake actuator model was designed to accurately model the response of the forebody strake actu- 
ators in software. The model receives strake commands as inputs from the SIB and hinge moment 
from the simulation, and this mode gives out the spool and ram positions, voltages, and ram veloc- 
ity as outputs to the SIB and then as outputs to the simulation. The actuator model calculates spool 
and ram positions in normal operational mode or in trail-damped mode. The models are imple- 
mented on a Versa Model Eurocard (VME) system which operates at 800 Hz. 

Box level testing checked the box and actuator interfaces. A function generator replaced the 
FCC and provided the command voltages to the interface box. The initial tests verified the interface 
box under steady-state conditions. A voltage was applied, and the actuator or actuator model posi- 
tion was verified. Once the steady-state inputs were evaluated, a full-scale ramp input was then 
used to evaluate the time history of the interface box and of the actuator and actuator model. After 
the ramps, a frequency response test was run to verify the dynamics of the servoloop. Failures were 
then introduced while a ramp was input to verify that the failure-detection circuits operated as 
expected. Table 3 indicates the failures that were introduced and in what level of testing these fail- 
ures were performed. After the failure-detection tests were run, BIT was tested, and failures were 
introduced to verify that the implementation detected the failures properly. 
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Table 3. Integration testing matrix. 


Failures 

Card 

level 

Box 

testing 

Integrated 

system 

System 

validation 

Ram position, 
high open 

Yes 

One channel 

Two channels with actuator 
and actuator model 

One channel 
Two channels 

One channel 
Two channels 

Ram position, 
low open 

Yes 

No 

No 

One channel 
Two channels 

Spool position, 
high open 

Yes 

One channel 

Two channels with actuator 
and actuator model 

One channel 
Two channels 

One channel 
Two channels 

Spool position, 
low open 

Yes 

No 

No 

One channel 
Two channels 

FCC command 
to strake 
interface box, 

Yes 

One channel 

Two channels with actuator 
and actuator model 

One channel 
Two channels 

One channel 
Two channels 

open 

Strake interface 
command to 
actuator or 

No 

One channel 

Two channels with actuator 
and actuator model 

One channel 
Two channels 

One channel 
Two channels 

actuator 
model, open 

LVDT excitation, 
open 

No 

One channel 

Two channels with actuator 
and actuator model 

One channel 
Two channels 

One channel 
Two channels 

Pressure discrete, 
open 

Yes 

One channel 

Two channels with actuator 
and actuator model 

One channel 
Two channels 

One channel 
Two channels 

Power, open 

Yes 

One channel 

Two channels with actuator 
and actuator model 

One channel 
Two channels 

One channel 
Two channels 

Shut off valve, 
open 

Yes 

One channel 

Two channels with actuator 
and actuator model 

One channel 
Two channels 

One channel 
Two channels 

Servocurrent, 

open 

Yes 

One channel 

Two channels with actuator 
and actuator model 

One channel 
Two channels 

One channel 
Two channels 
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Three major anomalies were discovered during box level testing. First, a grounding problem 
required the addition of a second 1.832-MHz clock instead of relying on a single clock to drive 
both servoloop boards. Second, a sign error was discovered in the spool position versus command 
current algorithm, requiring minor redesign. Third, the counter used to step through the BIT 
sequence would intermittently reset or arbitrarily jump to a different test. Troubleshooting revealed 
a shared ground between the digital BIT circuitry and the analog circuitry on the failure-detection 
board. This problem was documented but was deemed a nuisance. No fix was implemented, so 
the problem was carried through to the aircraft and often required multiple BIT operations before 
each flight. 

Integrated system testing was the next level. The RFCS provided the ability to program the 
OBES to generate identical ramps and square waves as those from the function generator. The tests 
which had previously been performed during box level testing were repeated with the interface 
box, actuator or actuator model, and FCC integrated. The only discrepancy noted during system 
integration testing was a lack of fidelity in the strake actuator model. This model was improved and 
testing continued. 

Upon completion of integrated system testing, system level validation was run. A high-fidelity 
simulation of the vehicle dynamics was integrated with the interface box, FCC, and actuators or 
actuator models. The flight software was installed in the RFCS, and testing similar to that per- 
formed in the integrated systems testing was performed (table 3). Time histories, frequency 
responses, and induced failures were run at various flight conditions. The MC modifications, 
RFCS, and total system were validated. This validation included displays and switchology as well 
as failures, mode transitions, time histories, and frequency responses. During validation testing, a 
single failure in the FCC command to the SIB would result in the actuator trying to respond to both 
commands simultaneously. Both channels’ servovalve commands versus spool position monitors 
would fail, placing the actuator in trail-damped mode. This single point failure combined with the 
discovery that trail-damped is an unacceptable failure mode, resulted in developing and implemen- 
tating the strake retract system. 

Additionally certain conditions, such as a single failure in a main ram LVDT signal, could 
cause a failure in the second channel. Such failures also resulted in the trail-damped mode. 
Troubleshooting revealed that the failure in the first channel ram position drove the command 
current in the partner channel higher momentarily to compensate. The servoposition versus com- 
mand current monitor failure discrete would momentarily trip and then self-reset. This transition 
typically lasted 20 to 25 msec. The optical relay which controls the actuator shutoff valve is spec- 
ified to recover from transitions in less than 50 msec. That relay would latch to a failed state and 
could not be reset because of the design decision not to include a manual reset. 

Aircraft integration testing was fairly limited because of high confidence in the simulation 
implementation. Testing consisted of time histories in the three RFCS modes. Open wire failures 
were induced to verify failure-detection, and cockpit functions were verified. The only known 
anomaly was the BIT problem discovered during integration testing. 
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RFCS VERIFICATION 


With the implementation of the ^-disengage software, the class B designation of the rest of the 
RFCS software was used to define the level of verification testing required before flight. Indepen- 
dent testing has shown that the RFCS envelope limits and the OBES are the only elements of RFCS 
which affect flight safety. Since those tests, the vane load limiting was also determined to affect 
flight safety. With this affect in mind, the ANSER verification testing requirements were defined. 
The RFCS envelope limits (15,000 ft < h < 45,000 ft, M < 0.7) were verified. A bit-for-bit compar- 
ison of the g-disengage software was performed to verify that g-disengage executable did not 
change from a previously verified version. The RFCS software configuration identifier was veri- 
fied to ensure that the software release identification was correct. Thrust-vectoring vane system 
(TVVS) command limiters were verified in the lower right- and left-hand comers of the envelope. 
Because the OBES could also affect safety of flight, each OBES maneuver was flown at flight con- 
ditions starting in the lower right-hand comer of the envelope to determine where in the flight en- 
velope the individual maneuver affected flight safety. Once this determination was completed, a 
flight operations limit was defined for that maneuver. Although some informal testing was per- 
formed to gain confidence in the operation of the software, no other RFCS software testing was 
required. Any errors existing in the software were considered to be only mission critical. The 
project decided to accept this risk knowing that a complete verification would take an unreasonable 
amount of time. 


FLIGHT TEST MONITORING 


Flight test monitoring of the RFCS and the processor FCS for phase 2 was done on two control 
room display pages. An FCS display page was designed to look similar to the FCS DDI display in 
the aircraft (fig. 17). This page displays leading-edge flap, trailing-edge flap, aileron, rudder, sta- 
bilator and TVV position and failure status; lateral stick, longitudinal stick and rudder pedal posi- 
tions, and failure status; and FCS analog and discrete I/O failure status. The RFCS display page 
was used to monitor the RFCS I/O and system functionality during RFCS engagement (fig. 18). 
Aircraft rates, accelerations, AOA, and rates of change in angles of attack and sideslip, a and P, 
were displayed with RFCS arm and RFCS engage-disengage limit windows. The TVVS com- 
mands and positions were displayed with maximum limits. The RFCS Mach number and altitude 
were displayed with RFCS envelope limits incorporated. Engine parameters included power lever 
angle (PLA), nozzle area, turbine discharge pressure, and gross thrust. The RFCS abort and fail- 
to-arm flags were also displayed. The TVVS temperatures and aircraft loads as a function of per- 
cent of maximum allowable were also displayed to allow for the option of not having a structural 
loads engineer in the control room. 


Earls, M.R., “Nasty RFCS Test Report,” HA92-84-601, 1992. (This report is an unpublished working paper and 
is not available to the public.) 
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Figure 17. The HARV RFCS monitoring page. 
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Figure 18. The RFCS monitoring page. 
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In addition to the existing RFCS and FCS display pages used on phase 2, other parameters were 
incorporated into display pages for the phase 3 (ANSER) portion of flight test. A new ANSER 
parameter display system (PDS) display page was designed for monitoring strake actuator com- 
mands versus actuator positions, servocurrents, spool positions, and failure-detection circuitry dur- 
ing flight (fig. 19). A BIT index was displayed for preflight BIT monitoring. The strake go flag, 
ANSER mode (TV, STV, S), trail-damped indication, FCS caution, and strake retract switch posi- 
tion were also displayed. The FCS caution was displayed to alert the systems engineer that an FCS 
problem existed. The systems engineer could then display the FCS display page to troubleshoot the 
FCS problem. The RFCS display page was modified for phase 3 to include ANSER mode, strake 
command, strake position, strake go flag, and current gain set selected. To indicate an ANSER 
mode transition (for example, TV — » STV) to the systems engineer, the ANSER mode would flash 
at approximately 5 Hz during the transition (figs. 18-19). Some of the more critical parameters, 
such as ANSER mode, trail damped, and strake go, were displayed on the ANSER PDS and the 
RFCS display pages. This combination display reduced the systems engineer’s scan during flight 
test when critical calls to the test pilot, flight controller, or both, were required. To isolate possible 
RFCS anomalies from SIB anomalies, the RFCS page displayed command and position data from 
the RFCS, and the ANSER PDS page displayed command and position data from the SIB. 
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Figure 19. The ANSER PDS page. 
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FLIGHT TEST RESULTS 


The ANSER system was installed and flown for the final 89 flights of the HARV flight 
program. With one exception, flight performance of the system was generally successful. The 
servoposition versus command current test would fail and self-reset during large amplitude lateral- 
directional maneuvers in the 30° to 50° angle-of-attack range. Typically, one channel of one actu- 
ator would indicate a failure. Troubleshooting revealed a divergence in the RFCS command to the 
servoloop between the two channels of the affected actuator. The two independent servoloops 
would command a different servovalve position based on the FCC commands. The servovalve 
would respond to a position midway between the two commands. When the commands diverged 
sufficiently, the failure-detection algorithm would declare a failure (fig. 20). The test tolerance was 
increased to allow the commands to differ by 8.5° or nearly 10 percent of full scale. This increase 
reduced the frequency of the failures, but it did not eliminate them completely. 



Figure 20. Example of in-flight command miscomparison. 


Investigations into the cause of the divergent FCC commands are ongoing. The RFCS channels 
appear to be receiving different values for lateral stick commands resulting from the quad signal 
selection algorithm in the FCC. The high gain nature of the RFCS control laws amplifies this dif- 
ference and results in the different strake commands. Documentation of these findings is hindered 
somewhat because internal FCC data are only available on two of the four channels through the 
MIL-STD-1553 data bus. Project scheduling concerns prohibited a resolution of this problem; 
therefore, a set of research data in the flight regime affected was not obtained. The probable fix 
would have been a persistence counter in the RFCS on the strake go discrete. These failures were 
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generally one or two frames in length. A five-frame persistence on the strake go discrete would 
have allowed the S or STV mode to remain engaged while the failure self-reset. 

Other problems encountered in the flight program were minimal. An integrated circuit failure 
occurred causing loss of one flight for repair. A failed spike suppression diode in an unrelated 
system caused corruption of strake power. This diode failure resulted in an self-start of the ANSER 
BIT logic in flight. The retract system was used, and the aircraft was recovered normally. 


LESSONS LEARNED 


Several lessons were learned in the development of the ANSER system. These lessons can be 
applied to future system integration efforts. An assumption was made early in the program that 
placing the actuators to trail-damped was an acceptable failure mode. This assumption drove a 
great deal of the system design and eventually proved false. A substantial effort was then required 
to implement the strake retract system. Had the assumption been disproved earlier in the design 
phase, the normal failure mode could have been to a strake-closed configuration. 

The decision to have failures automatically reset was adequate in the majority of cases, but 
when a main ram LVDT failure occurred, the partner channel servocurrent versus spool position 
monitor failed and reset faster than the electronics could recover. This rapid automatic reset result- 
ed in an unresettable trail-damped condition. The addition of a manual reset capability along with 
the automatic reset would have alleviated this problem. 

Monitoring the preflight built-in test manually rather than automatically proved to be a valid 
approach for this application. This monitoring eliminated the development of a processor-based 
system to perform this function. 

A persistence counter on the strake go discrete may have prevented the reversions to TV mode 
in the 30° to 50° angle-of-attack range during the flight phase. Additionally, a cross-channel com- 
parison of RFCS parameters may have detected the command miscomparisons, and a routine could 
have been implemented to average these signals. 

In the RFCS area, increased throughput and ROM would have eased the software design. 
Streamlining the code a great deal was necessary to accommodate these limitations of the RFCS. 


CONCLUDING REMARKS 


A system to enhance high-angle-of-attack flight handling qualities was developed by NASA 
Langley Research Center and integrated into the F-18 High Alpha Research Vehicle by NASA 
Dryden Flight Research Center. The actuated nose strake for enhanced rolling system proved reli- 
able throughout 89 test flights. This system consists of two actuated control surfaces installed on a 
specifically constructed radome. 
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Actuator control was performed by a strake interface box with commands generated by the con- 
trol laws residing in the research flight control system (RFCS). These control laws consisted of 
three modes: thrust vectoring (TV), strakes and thrust vectoring (STV), and strake (S). The TV 
mode uses the TV system for longitudinal and lateral-directional control. The strakes are not 
commanded in this mode. The system reverts to the TV mode in the event of a strake failure. The 
STV mode uses TV for longitudinal control and a combination of strakes with TV for lateral- 
directional control. The S mode uses TV for longitudinal control and strakes for lateral-directional 
control. The RFCS also resides in the onboard excitation system and allows open- and closed-loop 
functions to be summed into the RFCS control laws for research flexibility. 

Extensive testing was performed to qualify the system for flight. This testing revealed one ma- 
jor and several minor system problems. The major problem was that the failure mode for the sys- 
tem which had been designed to place the failed strakes in trail-damped mode was inadequate. This 
inadequacy could result in a out-of-control situation. This problem resulted in the implementation 
of a manually activated retract system to close the strakes if a trail-damped situation occurred. 

In the 30° to 50° angle-of-attack range, strake commands would differ between the two flight 
control channels driving a particular strake. This difference resulted in a reversion to TV mode. A 
correction was not implemented, and a portion of the flight research program was not completed 
because of this failure. With this exception, the program was generally successful, and the majority 
of the research objectives were met. 
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